نبذة تأريخية مختصرة عن الانترنت

تطوّرت الإنترنت نتيجة أبحاث بدأت في أوائل الستينيات حين عزمت وكالة مشاريع البحوث المتقدمة Advanced Research Projects Agency (ARPA), التي سميت لاحقاً بوكالة مشاريع البحوث المتقدمة للدفاع الأمريكي US Defence Advanced Research Projects Agency (DARPA) ) دخول مشروع ربط الحواسيب الرئيسية وتجربة شبكات واسعة النطاق wide area network (WAN) التي إمتدت عبر مدن وليات امريكا وذلك لتشكيل شبكة ذات عدة مراكز ،صممت هذة الشبكة اساسا لأغراض عسكرية وحماية شبكة الاتصالات العسكرية في الولايات المتحدة بحيث أنه عندما يتعرّض مركز من المراكز لضربة عسكرية فإن المراكزالأخرى تكون قادرة على إتمام عمليات الاتصال بطرق أخرى وغير مكترثة بما حدث لمركز أو مراكز مدمرة

في السبعينات أستمر فريق الابحاث DARPA بتمويل حكومي لتحفيز تطوير إطار شبكات الإتصالات ومواصلة إجراء بحوثات واسعة الى مايعرف ARPANET أو ARPA Network ، والنتجة من هذا الإطار هو بروتوكول السيطرة على الإرسال و بروتوكول الإنترنت Transmission Control Protocol/Internet Protocol (TCP/IP)

زادت قبولية أستخدام بروتوكول TCP/IP عند أبتكار DARPA هذا المشروع لمجتمع الحواسيب وكان لابد من تجربة أولية للمشروع وتمت تجربة هذة الشبكة في جامعة كاليفورنيا بيركيلي على نظام اليونكس Berkeley Software Design (BSD) تعرف ايضاً بتوزيعة بيركيلي المعيارية Berkeley Standard Distribution ، في ذلك الوقت ادخرت DARPA شركة تسمى Bolt Beranek and Newman, Inc. (BBN) لدعوة لمساعدة لتطوير بروتوكول TCP/IP على نظام اليونكس BSD ، فأتات هذة الدعودة لهذة التقنية الجديدة بعد أقامت العديد من المؤسسات تطوير الشبكات المحلية النامية للإتصال بين حواسيب محدود في منطقة محدودة المساحة .

في عام 1981 تم ادرج مصطلح الانترنت لربط عدة شبكات عالمية معاً ، وفي اوائل 1983 أصبحت جميع الحواسيب متصلة بالArpanet بتشغيل أتصالات جديدة تسمى TCP/IP التي صممت مقابس بيركيلي علية

في عام 1989 قامت مختبرات في اوربا تدعى Conseil Europeén pour la Recherche Nucléaire (CERN) بإبتكار شبكة الويب العالمية World Wide Web (WWW) كان هدف تطوير مفهوم الويب هو لإيجاد روابط بين الوثائق أو الصفحات الموجودة على الإنترنت فظهر مايعرف بالرابطة الفائقة hyperlink التي تتيح الانتقال من صفحة ويب إلى أخرى ومن موقع إلى آخر دون الحاجة إلى حفظ أي أوامر أو التدرب على أي مهارات للإستخدام مادة الأنترنت( hypertext النصوص التي تحتوى على hyperlinks )، إلى ان تتطورت مادة الانترنت من قبل المبرمجين لتضمن النصوص والوثائق مع أوامر الوسوم tags المضمنة من خلال <angle brackets> المعروفة بلغة ترميز النصوص التشعبي Hypertext Markup Language (HTML) اللغة المستخدمة في تصميم جميع صفحات الويب ومشاهدة صفحات الانترنت

في عام 1993 تمكنت National Center for Supercomputing Applications (NCSA) في جامعة Illinois من نشر أول متصفح روسمي Mosaic اعطى المتصفح شكلاً معيناً وشعوراً بالرحة لدى المستخدمين واصبح المستخدم قادر على مشاهدة صفحات الويب HTML بسهولة ، اول نسخة من Mosaic نزلت على انظمة اليونكس بإستخدام نظام X Window وفي اواخر 1993 نزلت نسخ للإنظمة ابل ماكنتوش ومايكرسوفت ونيدوز . في ذلك الوقت كان تقربياً هناك 50 خادم ويب Web servers يودي أرشفة للرؤية صفحات HTML ، وبعد تسعة اشهر عددها أزداد الى أكثر من 500 خادم ويب وبمضي العام أصبح هنالك اكثر من 10,000 في 84 بلاد يشمل World Wide Web وجميعها تشتغل على ARPANET الخطوط الرئيسية المسمى بالإنترنت .

تزود أسهمات الانترنت في الوقت الحاضر لملايين المضيفين في كافة أنحاء العالم ، وتسطيع البنية التحتية الحالية للانترنت تحمل اكثر من حجم 45 ميجابايت Mb لكل ثانية اي حوالي ألف مرة من الbandwidth للARPANET الاصلية ، (وعموماً Bandwidth يستخدم لقياس كمية سير بيانات(traffic)الوسائط المارة التي تعالج في المرة الواحدة بمعنى اخر هي كمية البيانات التي تنقل في خط الاتصال ووحدتة بالبت لكل ثانية bps اختصار bits per second.)

مقــدمة

يستند الانترنت على بروتوكول السيطرة والإرسال Transmission Control Protocol/Internet Protocol(TCP/IP) ، واغلب تطبيقات الشبكات مستندة على application programming interface(API) في برمجة الشبكات لتواصل مع البروتوكول وتعرف هذة البرمجيات بمقابس بركيلي Berkeley sockets في أنظمة اليونكس ، ويشمل نجاح بروتوكول TCP/IP جزيئا ً بسبب وجود مقابس API التي متؤفرة على أغلب لغات البرمجة كالـC, C++, Java, BASIC, Python, COBOL, Pascal, FORTRAN وايضاً في البيرل ، وهذة API متشابة في جميع هذة اللغات ، والحقيقة أن البيرل تقوم بالوصول المباشر الى مكتبه السي للاتصال بالمقبس وغالباً بارامتر الدوال والقيم العائده هي ثوابت معرفة في الملفات الرائسية للسي ، وايضاً data structures التي تقوم البيرل بمرورها على صيغة رزمbinary ، والموديل Socket الذي يقوم بإنجاز هذه الثوابت وايضاً العديد من الدوال للضغط وفك الضغط لهذة الـ data structures .

ولكن البيرل اكثر سهوله من لغة السي بتزويد الكثير من الدوال وايضاً لها الكثير من الوحدات البرمجية المتوفره بحريه تامة التي تجعل من الوصول إلى المهام بسهوله واكثر سرعه ، في بقية الفصول القادمة سنتعرف على هذة المهام كالـ ping و TELNET و FTP ... وتقديم بعض الامثله على مختلف انواع برامج الشبكه و إستعمالها لأنشاء برامج client/server .

من ميزات البيرل عن باقي اللغات فهناك إختلاف بسيط بين فتح قناة الاتصال للقراءة البيانات من ملف في جهازك المحلي وفتح المقبس للقراءة البيانات من برنامج بعيد على جهاز اخر في مكان ما على الانترنت ،وأيضاًَ لكؤن أغلب البيانات على الانترنت نصوص فهي ميزة اخرى تضاف بحيث نستطيع تضمين التعبيرات المنتظمة مع برنامج الشبكة لمعالجة النصوص، وايضاً اسهل في التعامل مع برامج المخاطبة بين العمليات IPC والبورت جيد وغير متقلب وتؤفر البيرل الدعم الكامل للمقابس بيركيلي على اكثر أرصفة التشغيل كالونيدوز والماكنتوش وتجعل من التطبيق قابل للنقل portable في اكثر من بئية تشغيل اخرى وايضاً عدم وجود ثغرات كالثغرات الفيض وتجاوزات اخطاء الذاكرة memory overrun errors بعكس في حالتة كتبت برنامج الشبكة في السي أو C++ سوف يصبح صعب جداً ومن المحتمل يكون غير أمان وكذلك السرعة والكفاءة في برنامجك .

من بين السمات الاخرى للغة البيرل عن باقي للغات البرمجة:

• هناك إختلاف بسيط بين فتح قناة الاتصال لإجراء عملية قراءة للبيانات من ملف في جهازك المحلي وبين فتح المقبس لإجراء عملية قراءة للبيانات من برنامج بعيد على جهاز اخر في مكان ما على الانترنت

• لان أغلب البيانات على الانترنت هي من النصوص تلك ميزة اخرى تضاف بحيث نستطيع تضمين التعبيرات المنتظمة مع برنامج الشبكة لمعالجة النصوص .

• اسهل في التعامل مع برامج المخاطبة بين العمليات IPC والبورت جيد وغير متقلب

• تؤفر البيرل الدعم الكامل للمقابس بيركيلي على اكثر أرصفة التشغيل كالونيدوز والماكنتوش وتجعل من التطبيق قابل للنقل portable بغض النظر عن نظام التشغيل المستخدم

• عدم وجود ثغرات كالثغرات الفيض وتجاوزات اخطاء الذاكرة memory overrun errors بعكس في حالتة كتبت تطبيقات الشبكة في السي أو C++ سوف يصبح الامر صعب جداً عليك وفي الاخير من المحتمل يكون غير أمان وكذلك السرعة والكفاءة في برنامجك .

Clients, Servers, and Protocols

يحدث الأتصالات بين برنامجين في الشبكة لتبادل البيانات فيما بينهم يسمى أحدهم العميل client يبدأ الإتصال الى البرنامج الاخر الخادم server عادتاً وليس دائما لانه يكون في حالة passive ، يعد الخادم إلى إنتظار جهات إتصال (contacts) حتي يتصل بة أحد العملاء بنفس الوقت ايضاً لابد من ان يشترك العملاء مع الخادم بالخدامات الاتصال نفسها ، فعند انشاء اتصال لابد من اشتراك العميل والخادم بخدمة service معينة لتوافق البرنامجين ويتم تبادل البيانات فيما بينهم .

لتوضيح مفهوم الخادم والعميل سنتعرض المثال التالي ، متخصص في بيع الوجبات يتم الخدمة فيه بأن يقوم الخادم (العامل)بأخذ طلبات العميل (الزبون) وتحديد قيمة الطلب وإستلام القيمه ثم منادلة الطلب وبعد ذلك ينصرف الزبون ويقوم العامل بتقديم الخدمة الى زبون آخر وهكذا ...، هذة العملية هي مثال لمركز خدمة ذات خادم واحد

هناك الكثير من الخوادم وبالمثل للعملاء من حيث عملها بغض النظر عن نظام التشغيل المستخدم مثل file servers,Print servers,application servers,Communication servers,Database servers..الخ ، يتطلب لتشغل الخادم حاسوب ذات معدات وموصفات كبيرة و قوية أكبر من جهاز العميل الا ان ذلك ليست بالقاعدة فإغلب التطبيقات شعبيتاً كنظام X Windows والبرامج الرسومية الاخرى اليوم تحتاج الى ذاكرة وموصفات قوية مع ذلك يوضع الخادم في كمبيوتر محمول أو جهاز سطح مكتب بينما العميل يشغل على جهاز "server class" أكثر قوتاً .

ان أغلب بروتوكلات الشبكة التي تستعمل اليوم مع تطبيقات الخادم والعميل تساعد على مرور المعلومات من جهاز الى جهاز اخر على الشبكة فمثلاً يستخدم بروتوكول HTTP في الويب ، وبرتوكول SMTP لإيملات الإنترنت الى ذلك من البروتوكلات الوصول المعرفة في قاعدة البيانات البروتوكول ،

Protocols

البروتوكول هو مجموعة من الإتفاقيات بناءاً على المعيارية الموحدة على الشبكة حيثما برنامجين يعملان معاً ، اي أنها مجموعة من قواعد التخاطب والخطوات المتبعة لتحقيق الاتصال بين الحواسيب على الشبكة أو بين الشبكات المختلفة فهي بمثابة لغة تفاهم بين الحواسيب على الشبكة ، وهناك باقة من البروتوكلات في النموذج على جميع مستويات مكدس الشبكة Protocol Stack او TCP/IP protocol suite ، تصف الصورة التوضحية التالية كيفية نقل البيانات من جهاز الى جهاز آخر :

في المستوى الاوطي هي للطبقة العتاد hardware layer (ويطلق عليها ايضاً بنفس الاسم Physical layer أو datalink layer أو Network interface layer ) فمثلاً المحرك drivers المبني لكروت وصلة الشبكة Ethernet لديها فهم موحد في كيفية ترجمة نضات الجهد الكهربائي على سلك الشبكة في مصلاح Ethernet frames كما تكتشف هذة الطبقة عندما السلك يستخدم من قبل بطاقة أخر وكيفية الحلول لحدوث التصدمات collisions بين بطاقتين لمحاولتهم الإرسال في نفس الوقت .

في المستوى طبقة الشبكة network layer ، في هذة الطبقة يتم تجميع المعلومات لتصبح رزم packets تتكون من رأس وحمولة ، يحتوي الاول الرأس header على عنوان المرسل والمستلم ، بينما تحتوي الحمولة payload على البيانات الفعلية المرسلة ، وعادتاً مدى الحمولات من 500 بايت الى 1500 بايت ، والشي المهم بأن موجهات الأنترنت routers تعمل على طبقة بروتوكول الأنترنت IP layer بقراءة روس الرزم packet headers ثم توجهها الى هدفها بعملية تسمى routing ، نلاحظ من هذة الطبقة ان البروتوكول الرئيسي هو Internet Protocol, او IP

تهتم طبقة النقل transport layer بإنشاء رزم البيانات وضمان سلامة محتوياتها ، والبروتوكلات المهمة في هذة الطبقة هما Transmission Control Protocol (TCP) الذي يحقق تواصلات أتصال موجهه (connection-oriented communications) بموثوقية عالية لتسليم البيانات ، والبروتوكول الاخر هو User Datagram Protocol (UDP) الذي يحقق خدمات رسائل موجهه (message-oriented service) ولكن غير موثوقة لتسليم البيانات ، ومسئولية هذة البروتوكلات في طبقة النقل لجلب البيانات الى المستقبل ولان تهتم ماالذي هو داخال inside سيل البيانات data stream.(بمعنى مسئولة عن نقل البيانات الى وجهتها فقط )

في قمة المكدس طبقة التطبيق application layer ، حيث محتوى سيل البيانات المهتمة ، ومتوفر في هذا المستوى العديد من البروتوكلات بضمن ذلك الاسماء المعروفة كالHTTP, FTP, SMTP, POP3, IMAP, SNMP, XDMCP, NNTP ، وتحدد هذة البروتوكلات في بعض الاوقات في تفصيل مفرط وكيف العميل سيتصل بالخادم ، وما الرسائل المسموحة وماهي المعلومات للتبادل مع كل رسالة

تعرف طبقة الشبكة وطبقة النقل معاً بأسم TCP/IP التي تشتغلان بنفس تلك الطبقات .

تتم عملية الإتصال بين برنامجين كما يلي : يتم إدخال البيانات المطلوب إرسالها بواسطة تطبيق الشبكة وتنتقل هذة البيانات ويتم ترجمتها بالمرور على كل الطبقات في الجهاز المرسل ابتداء بطبقة التطبيق وانتهاء بطبقة العتاد حيث تكون البيانات قد تحولت الى bits جاهزة للنقل عبر الأسلاك بعد ان تضيف كل طبقة معلومات header الخاصة لكل طبقة الى البيانات التي ترغب في إرسالها وتسمى هذة العملية Encapsulation وعند وصولها الى الجهاز المستقبل تمر البيانات بالطبقات بشكل معكوس ابتداء بطبقة العتاد و انتهاء بطبقة التطبيق في عملية تسمى De-Encapsulation وتكون البيانات الناتجة هي مايراه المستخدم المستقبل على جهازه .

بروتوكلات النصوص الموجهه مقابل بروتوكلات الثنائية الموجهه Binary versus Text-Oriented Protocols

قبل ان يتبادل العميل والخادم المعلومات عبر الشبكة فسيكون لدى المضفين خيارات فاما أن يتم التبادل في الصيغة الثنائية أو النص العادي المقروء ، فمثلاً بإعتبار تبادل العدد 1984 في الصيغة النصية text ، يحول المضيف هذة الأعداد الى مجموعة نصوص ASCII مقابلة بالهكس 0x31 0x39 0x38 0x34 ثم تنقل الاربعة بايب عبر الشبكة ، التي تظهر ايضاً على المضيف الاخر في ASCII كال "1984" ، بينما نستطيع ان نمرر العدد 1984 كعدد بأثنين بايت صحيحة integer ممثلة في الهكس 0x7C0 ، وفي حالة تخزن العدد في المضيف المحلي كعدد وليس كنص فسنقل عبر الشبكة في two-byte بدلاً من تحويل كل أربعة بايت text ثم نقل والتحويل لاحقاً الى عدد من أثنين بايت في المضيف الاخر ،وليس ذلك فقط بل تستخدم الصيغة الثنائية بعض الحسابات والتحويلات وتستخدم نصف قدرة الشبكة network capacity.

هناك بعض الاختلافات في معمارية الحاسوب في تخزين الأعداد الصحيحة والأعداد الحقيقة ، فالأعداد الحقيقية في بعض الاجهزة تستخدم من two-byte integers وبعضها من four-byte integers وبعضها من eight-byte integers ، مايعرف بحجم الكلمة "word size"، كذلك لدى معمارية الحاسوب أتفاقيتان مختلفة لخزن الأعداد الصحيحة في الذاكرة ، فمثلاً في بعض الأنظمة تعرف بالمعماريات big-endian ، وغالباً من هذة المعمارية يخزن العدد الصحيح في أول بايت للبايتات الأثنين الصحيحة ،فعلى هذة الأنظمة يقراء من low الى high ويمثل العدد 1984 في الذاكرة 2 بايت

0x07    0xC0
low  -> high

أو على معماريات little-endian تعكس هذا الإتفاقية ويخزن العدد 1984 في الذاكرة بتوجية معاكس

0xC0    0x07
low  -> high

تلك المعمارية هي مسألة إتفاقية وليس لها فائدة هامة على معمارية المضيفين نفسها ، تأتي المشكلة عند نقل البيانات عبر الشبكة بشكل متتابع لزوج البايت(2 البايت) التي ترسل البيانات من الذاكرة عبر الشبكة من low الى high لذلك سينقل حواسيب big-endian الرقم 1984 في طلب 0x07 0xC0 ، بينما حواسيب little-endian سترسل في طلب معاكس ، وطالما الاجهزة في الطرف الاخر لدية نفس حجم الكلمة ونفس طلب البايت فستكون صحيحة ، بينما اذا كان الطلب مختلف للبايت فسترجم الأثنين بايت في طلب خأطى وسنحصل علي 0xC007 او القيمة العشرية لها 49,159 ، ولربما أن يترجم الهدف هذة البايتات من أربعة بايت integer ويظهر في الشكل 0xC0070000 أو القيمة 3,221,684,224 .

بسبب هذة الأختلاف في الصيغة الثنائية ، فأن البروتوكلات المستندة على النصوص text هو المعيار الاوحد في الأنترنت ولجميع البروتوكلات المشتركة في الشبكة مثل (TCP/IP ,OSI,IPX, AppleTalk,DECent) ، تحول المعلومات العددية الى النص ثم نقلها فيما بعد بالرغم من كثرة البيانات في النقل ، كذلك فبعض البروتوكلات تحول البيانات الغير نصية كالملفات الصوت الى الصغية التي تسعمل مجموعة ASCII لأن ذلك أسهل عموماً ، ونفس الشئ مع العديد من البروتوكولات الكبيرة هي line-oriented بمعني قبلول الأوامر وتسليم البيانات في شكل سطور متقطعة وكل طرف في أتفاقية السطر الجديد newline لنظام التشغيل .

بطبيعة الحال بعض البروتوكلات في الشكل الثنائي فمثلاً بروتوكول Remote Procedure Call (RPC) التابع لنظام Sun's وبروتوكول Napster peer-to-peer file exchange protocol ، فمثل هذة البروتوكلات يجب ان تكون حذراً لتمثيل البيانات الثنائية حتى تصبح صيغة موحدة في الحواسيب المختلفة . هناك صيغة متعارفة للأعداد الصحيحة عموماً في الشبكة ، في صيغة الشبكة network format العدد الصحيح "short" يمثل في 2 بايت big-endian ،بينما العدد الصحيح "long" يمثل مع 4 بايت big-endian ، سنرى لاحقاً في الفصل 19 الدوال pack() ، unpack () التي تودي تحويلات الاعداد الى صيغة الشبكة ثم بأعادتها مرة اخرى .

الأعداد الحقيقية والأشياء المعقدة أكثر فمثلاً هياكل البيانات data structures ليس لاتمثل مقبول عموماً عندما يتبادل البيانات الثنائية لكل بروتوكول لة طريقة خاصة لتمثيل البيانات في أختلاف أنظمة التشغيل .

مقابس بيركيلي

مقابس بيركيلي جزء من API بضمن الدوال وتركيب البيانات المتفاعلة بنظم الشبكات في نظام التشغيل ، وعرف هذا الاسم في ظهور برمجيات API لتوزيعة اليونكس Berkeley Standard Distribution (4.2BSD) وتمثل مقابس بيركيلي في طبقة النقل transport layer التي تعتبر كوسيلة نقل تساعد للحصول على البيانات حيثما ذهبت ، فمقابس بيركيلي جزء من API وليس هنالك بروتوكول محدد التي تعرف عن كيف يمكن للمبرمج ان يتفاعل بشكبة مثالية ، بالرغم من اقترانها مع بروتوكول الشبكة TCP/IP التي صممت API علية ، عممت API مقابس بيركيلي الدعم الكافي للجميع أنواع الشبكة مثل Novell Netware, Windows networking, Appletalk.

تزود البيرل دعماً كاملاً للمقابس بيركيلي على أغلب الأرصفة التي تشغل عليها كأرصفة Windows و Macintosh كما توفر البيرل في هذة الأنظمة وحـدات ممتدة للوصول الى البرمجيات التفاعلية ليست للبيركيلي ولكننا نهتم في كتابة تطبيقات قابل للنقل والتمسك بتطبيقات بيركيلي .

المقبس هو نقطة النهاية للإتصالات اي البوابة الى العالم الخارجي التي يمكننا من أرسال رسائل خارجة الى عملية أخرى ،وإستلام traffic قادمة من العمليات الينا. ولإنشاء المقبس نحتاج لتزويد النظام على حد أدني الى ثلاث خصائص:

خصائص المقبس

1. عائلة العنوان

2. النوع

3. بروتوكول الإتصالات

مجـال المقبس

يعرف المجال domain عائلة بروتوكلات الشبكة ومخطط العنونة التي تدعم المقبس ، ويحدد هذا المجال بعدد صغير من الثوابت الصحيحة المعرفة في نظام التشغيل والمصدرة بوحـدات مقابس البيرل وهناك مجالين موحدة فقط في الشبكة مشاهدة في الجدول التالي

AF_INET يستخدم بروتوكول TCP/IP للإتصال بجهاز اخرى على الشبكه في مجال الإنترنت (Internet) ، ويستخدم المقبس في هذا المجال عناوين IP وأرقام المنافذ كما هي في مخطط العنونة لدية ،بينما يستخدم AF_UNIX فقط للتخاطب بين العمليات IPC ضمن مضيف host واحد فقط كما أن العناوين في هذا المجال هي مسارءات الملف ،و لايشير هذا المجال الى تضمين UNIX-specific الى تحديد نظام اليونكس وبسبب هذا فأن معيار POSIX أعادت تسميتة الى AF_LOCAL

هناك العديد من المجالات كال AF_APPLETALK, AF_IPX, AF_X25 , AF_DECnet ... كل منهم لدية مخطط العنوانة الخاص المقابل لة ، فمثلاً AF_INET6 التي يقابلها عناوين طويلة لنسخة Internet Protocol version 6(IPv6) لعنونة تصل الى 128 بت اي مايعدل ضعف بأربع مرات لطول عناوين AF_INET أو IPv4 ذو 32 بت .

تشير تقديم AF_ الى إنتماء الى عائلة العنوان "address family" وهناك مجموعة من الثوابت لعائلة البروتوكول "protocol family" التي يتقدمها PF_ فمثلاً هناك الثابت PF_INET الذي هو مماثل الى AF_INET ويقدر هذة الثوابت بنفس القيمة والعمل ، الميزة بينهم في الصناعة القديمة في واقع الامر وسنرى ذلك في العديد الكود المنشورة حيث يستعمل كلهما بدون إختلاف .

نوع المقبس

يميز نوع المقبس الخصائص الاساسية للإتصالات المقابس ، فالمقابس ذو النوع "stream" في حالة البيانات المرسلة عبر المقبس في سيل مستمر ( كما هي القراءة والكتابة الى الملف ) بينما النوع "datagram" في حالة البيانات المرسلة والمستلمة في رزم متقطعة .

يعرف نظام التشغيل مجموعة من ثوابت النوع ذات القيم الصحيحة ، وجميع الثوابت الموحدة في أنظمة التشغيل والاكثر أستخداماً في المقبس والمصدرة بواسطة Socket كما يلي :

تدعم البيرل كلاً من أنواع المقبس SOCK_STREAM , SOCK_DGRAM بينما تدعم SOCK_RAW عن طريق موديل إضافية تسمى Net::Raw .

بروتوكول الإتصالات

بالاظافة الى مجال المقبس والنوع هناك العديد من البروتوكلات التي تزود الشكل المطلوب في الإتصال ، وكما هو مجال المقبس ونوع المقبس لدي البروتوكول قيمة صحيحة معرفة في نظام التشغيل ،ومع ذلك تلك الأعداد غير متؤفرة كثوابت ويمكن أنجاز بعض الدوال كالدالة getprotobyname() في وقت التشغيل ، والبروتوكلات المستخدمة بشكل رئيسي هي

بروتوكلات النقل(UDP ,TCP) وكلاً منهما بروتوكلات نقل يديران عملية ايصال البيانات الى تطبيقات محدده على الجهاز التي سوف تتوجه اليه . والاختلاف بينهما اذا لايقوم UDP بتثبيت link للإتصال بين منفذين عنوانين IP لكلاً من المصدر ووجهته و يقدم عملية نقل غير موثوقة ولكنه يمتازبأفضل سرعة ممكنة في عملية النقل لانة لايملك آليات تحقق من وصول البيانات كاملة ، بينما يقوم TCP بتثبت link للإتصال بين منفذين عنوانين IP لكلاً من المصدر ووجهته و يقدم عملية نقل موثوقة مع مراقبة وتحكم بعملية التدفق للبيانات ومع تصحيح للأخطاء الناتجة عن النقل وتبادل المعطيات بين الجهازين .

أصبحت أكثر أنظمة التشغيل توفر دعماً لبروتوكلات IPv6 وينعكس هذا الدعم في تضمينهم مع المقابس ، فبعضهم يعالج بعض البروتوكلات كال IPX, X25, or AppleTalk, وجميعها يمكن أن تستعمل من خلال المقابس بشكل ملائم ، وطبيعة البروتوكول يهتم لكي يملء نوع البيانات التي ترسل وتستلم ، أهتمامنا في هذا الجزء على مقابس السيل streaming المستخدمة مع بروتوكول TCP(connection-oriented) ، ومقابس datagram المستخدمة مع بروتوكول UDP(connectionless) ، وهذة البروتوكلات (TCP و UDP) مدعوم مباشرتاً بمقابس البيرل وللحصول على بروتوكلات ICMP و raw عن طريق الوحـدات Net::ICMP و Net::Raw ، في هذا الجزء لان نستخدم الرزم الخامة بإستخدام مقبس “raw” لإنشاء مقبس منخفض المستوى جداَ للعمل المباشر مع بروتوكول IP .

عند إنشاء المقبس يجب توخي الحذر في وضع المجال ونوع المقبس والبروتوكول المحدد ، التالي المجموعة المحتملة الاكثر استخداماً ومايقابلهم :

نلاحظ من عنوان العائلة AF_UNIX لايستعمل أسماً للبروتوكول بل يستعمل مايعرف pseudoprotocol المسمى PF_UNSPEC (اختصار"unspecified")

Datagram Sockets

كما نشاهد في الشكل لخدمة datagram لرزم البيانات في النظام البريدي للرسائل والبرقيات حيث تمر كل رزمة في هذا النظام إلى العنوان المقصود وعنوانة يعاد وكمية معينة من البيانات ، لعدم وجود آليات تحقق سيبذل بروتوكلات الإنترنت أفضل جهداً وأسرع لتسليم الرزم الى هدفها .

ليس هناك علاقة وطيدة بين مقبس الإرسال ومقبس الإستقبال لكؤن مقدرة عديمة الإتصال (connectionless) من إرسال البيانات دون تثبت establishing إتصال مسبق بين العميل والخادم ،فبهذا السبب من الممكن ان يرسل العميل رزمة off الى الخادم ثم يستدر فوراًَ في ذلك الوقت ويرسل الرزمة الى خادم اخر بإستخدام نفس المقبس ، وهذا مشابة UDP server حيث يستلام العديد من الرزم من مختلف العملاء على نفس المقبس .

على الرغم من طبيعة عديمة إتصال بروتوكول UDP أسرع الا انها تأتي بتكلفة، فمثلاً كأنظمة البريد في بعض البلدان ، يحتمل بعد أعداد الرزم وإرسالها أن يفقد البريد ، أيضاًَ لايعرف العميل ما اذا تسلم الخادم رسالتة حتى يتسلم اعتراف acknowledgment في الرد ، مع ذلك حتى أنة ليس متاكداً من ان الرسالة قد فقدت لكؤن ان الخادم ربما إستلم الرسالة الأصلية و الإعتراف acknowledgment قد فقدت طريقها .يمكن من بناء الكثير من الميزات الى تطبيقات UDP مثل : إمكانية عمل acknowledgments إلى الجهه الاخرى ، ونستطيع إعداد timeouts ، و إعادة إرسال رزمة البيانات تلقائياً في حال عدم تسلمها الى UDP socket .. الى غير ذلك .

أيضاً رزم Datagrams ليست متزامنة ولايوفر تحكماً بتدفق البيانات(flow control) ، فمثلاً عند أرسال مجموعة من الرزم الخارجة في طلب معين يمكن أن لا تصل الرزم في ذلك الطلب وتسلك طرق مختلفة، فمثلاً قد تذهب أول رزمة الى الطريق A و لربما تأخذ الثانية الطريق A لكن في مسار مختلف ، واذا كان توجيه routing الثانية أسرع من المسار الاول فأن الرزمتين ستصلنا في طلب متناقض للجهاز الذي أرسلت منه ، ويحتمل أيضاً حصول على رزمة بيانات متكررة في النقل (بتسليم نفس الرسالة مرتين ).

لكون طبيعة عديمة الإتصال ولايوفر تحكماً بتدفق البيانات بين المرسل والمستقبل ، أذا أرسل المرسل الرزم أسرع من المستقبل يمكن لمستقبل معالجتها ولكن ليس هنالك طريقة للإشارة signal إلى المرسل من أبطأ السرعة لذلك يبدأ بنبذ الرزم في أخر الامر.

تكلمنا ان بروتوكول UDP ليس موثوق من تسليم محتوياته الأ ان بعض التضمينات الحديثة تزود لكل رزمة بالآليات التحقق checksum لضمأن سلامة بياناتها وعدم فسادها أثناء النقل .

Stream Sockets

النوع الاخر الرئيسي هو مقابس السيل المضمن في مجال الإنترنت لبروتوكول TCP الذي يعمل بشكل متسلسل لسيل البياتات الموجهه byte-oriented وهو موثوق الإتصالات في كلا الإتجاهين bidirectional ، كما يعرض في الشكل يشبه مقابس السيل كثيراً المكالمات الهاتفية فلابد لبداء المحداثة بين العميل والخادم من تثبيت الإتصال ومن ثم بداء الجلسة والتواصل بينهما لتبادل البيانات لفترة زمنية ثم يقطع أحدهما الإتصال .

القراءة والكتابة الى مقابس السيل هي كالقراءة والكتابة للملف ، وليس هناك حد للحجم أو حدود للسجلات الموجهه بالرغم من أنك تستطيع أجبار تركيب معين للسجل الموجهه على السيل أذا أحببت ، ولكون مقابس السيل متسلسلة وموثوقة الإتصال يمكنك كتابة مجموعة متسلسلة من البايت إلى المقبس بأمان بمعرفة الطرف الاخر التي يظهرون علية في طلب صحيح ( لانعني بموثوقية TCP بأنة محصن ضد أخطاء الشبكة ).

يوفر TCP تحكماً بتدفق البيانات بخلاف UDP حيث من الخطر حشو بيانات مستلمة الى buffer ،وهذا الذي يعطي بشكل آلي لبروتوكول TCP حيث يعطى إشارات signals إلى المضيف المرسل لتعليق النقل موقتاَ عندما يتخلف المضيف من القراءة بسبب ملىء الى حد لايستطيع القراءة ، تستأنف أرسال البيانات عندما يصبح المضيف مستعداً لقراءة مرة اخرى ، ويحدث هذا التحكماً بتدفق البيانات flow control وراء الستار وغير مشهاد عموماً .

لا يختلف كثيراً مقابس السيل بأستخدام صيغة open(FH, " | command ") للفتح أنبوب إلى برنامج خارجي ، سواء فحسب على خلاف الأنابيب مقابس السيل ذو أتجاهين .

تؤدي مقابس السيل إتصالات موثوقة ذو أتجاهين ونقل متسلسل ما معنى هذا؟

• يودي بروتوكول TCP الموثوقية ،عندما يرسل TCP البيانات الى الطرف الاخر يتطلب acknowledgment في الرد ، وبعد أستلام رد acknowledgment سيعيد من إرسال البيانات وينتظر بعض الوقت للرد .بعد عدة أعادات إرسالات retransmitted تلقائية (ان فشلت جميعها على عكس UPD لايعيد من إرسال الرزمة في الفشل ) يتخلى عنها TCP معطياً كمية الوقت الإجمالي الذي مضى time spent في إرسال البيانات ، نموذجياً هو بين 4 إلى 10 دقائق (يعتمد على التضمينات implementation في النظام الشبكي ) .

  يحتوي TCP على خوارزمية لتقدير الوقت الإنكفائي round-trip time (RTT) بين الخادم والعميل بشكل "ديناميكياَ " بمعنى معرفة كم من الوقت المقدر لإنتظار رد acknowledgment . على سبيل المثال يقدرRTT على الشبكة المحلية LAN بالملي ثانية milliseconds بينما يقدر عبر الشبكة الواسعة WAN بالثواني وذلك بحسب المسافة وسرعة الشبكة واكتظاظ الشبكة . بروتوكول TCP يقدر RTT باستمرار في وقت التشغيل Run-time للإتصال المعطى وذلك لان تأثير RTT دائماً تكون متقلبه (اي لايمكن قياسها بمدى معين ) في network traffic .

• يودى بروتوكول TCP تسلسل متعاقب للبيانات عن طريق إقرانها بعدد متسلسل مع كل بايت مرسل ، يستخدم هذا العدد لتكوين جميع البيانات فمثلاً بإفتراض ان التطبيق يكتب 2,048 bytes الى مقبس السيل ، بما ان البيانات كبيرة لذلك يرسلها TCP في قسمين منفصلين ، الاول يحوي البيانات مع إعداد متسلسلة 1–1,024 والثاني يحوي البيانات مع إعداد متسلسلة 1,025–2,048 ( القسم segment :هو وحدة البيانات التي يمررها TCP الى IP ) .بوصل الاقسام segments الى الطرف الاخر يستلمها TCP ، بعد ذلك يقوم الاخير بإعادة ترتيب الاقسام الاثنين وذلك بحسب أرقام التسلسل قبل مرور البيانات الى التطبيق المستلم في طبقة التطبيق .عندما يستلم TCP بيانات مكررة من الند (قد يظن الند بأن القسم قد فقد لذا يعيد الإرسال بينما هي لم تفقد لانها مازلت تحمل زائد في الشبكة ) يكتشف ذلك من خلال إرقام التسلسل المتشابة ونبذ المتشابه منها .

  بالمقابل UDP ليس موثوق ،ايضاً ان UDP نفسه لايودي اي شيء كال acknowledgments,أو أرقام التسلسل ,أو تقدير RTT ,أو timeouts, أو إعادة الإرسالات .واذا تكررت رزمة بيانات UDP في الشبكة يمكن ان تسلم النسختين المكررة الى المضيف المستلم ، وايضاً اذا ارسل عميل UDP رزمتين الى نفس وجهته ليس من المحتمل ان تسلم في نفس الطلب .

• يوفر TCP تحكماً بالتدفق flow control ، دائما TCP يخبر الند ( كم بالضبط ؟ )بعدد bytes البيانات التي مستعد قبولها من الند في أي وقت .هذا يسمى بالنافذة الإعلان advertised window .النافذة هي كمية الغرفة الحالية المتوفرة في buffer المستقبل بكل وقت، للضمان عدم استطاعة المرسل من حشو بيانات overflow الى buffer المستقبل .ان النأفذة تتغير "ديناميكياَ " مع الوقت : بما ان البيانات مسلمة من المرسل فأن جحم النافذة تنخفض .ولكن بما ان (طبقة التطبيق) التطبيق المستلم يقراء البيانات من buffer فأن حجم النافذة تتزايد . من الممكن ان تصل النافذة الى الصفر عندما يكون buffer المستقبل TCP's للمقبس مملوئ لذا يتوجب علية إنتظار قراءة البيانات من الbuffer الى التطبيق قبل ان ياخذ مزيد بيانات من الند .

• أتصال موجهه ذو أتجاهين full-duplex ، يمكن للتطبيق من إرسال وإستلام البيانات في كلا الاتجاهين اثناء الاتصال في أي وقت ، وهذا يعني بأن TCP يتوجب علية أن يتتبع ما يعرف بمعلومات الحالة state information مثل أعداد التسلسل وحجم النافذة لكل إتجاه (إرسال و إستقبال ) تدفق البيانات . ان Datagram Sockets ترسل أو تستلام (طريق واحد directional) اي لايمكن التعامل مع مقابس UDP عبر طريقين فأما ان نقراء منه أو الكتابة الية انما بالامكان مع مقابس TCP ان نقراء منه والكتابة الية بنفس الوقت . بعدما يثبت الإتصال ذو إتجاهين يمكننا إغلاق اتجاه بواسطة shutdown() كما يمكن وضع أعدادات خاصة لبروتوكول UDP ليصبح full-duplex ,Timeout ، retransmission ، Sequence numbers ، Flow Control .

مقارنةً بين مقابس السيل ومقابس كتلة البيانات

تسخدم أغلب برامج client/server على الأنترنت مقابس سيل TCP ، لكن في بعض الأحوال من الافضل أختيار بروتوكول UDP فمثلاً في الخوادم التي تعطي الوقت time servers تستعمل رزم UDP datagrams لنقل وقت اليوم إلى العملاء لتزامن الساعة ، فأن تلأشت الرزمة في النقل فليس من الضروري أعادة أرسال الرزم مرة اخرى لان الوقت قد مر ولان يكون متعلق بالوقت .

يفضل UDP ايضاً متى ما كان التفاعل قصيراً جداً بين مضيف وأخر ، حيث ان طول الوقت للبدء وأعداد أتصال TCP هو حولي عن 8 أضعاف أكبر من التبادل لبايت واحد من البيانات خلال UDP ( للتفصيل شاهد [Stevens 1996]) ،فاذا كانت هناك كمية صغيرة من البيانات للتبادل وتم إعداد TCP من يتحكم في الاشرف على الأداء ، حتي بعد أن يثبت established أتصال TCP فكل بايت ينقل يستهلك أكثر bandwidth من UDP بسبب الأضافات للضمان السلامة.

يحدث السيناريو الاخر عندما يتوجب على المضيف من أرسال نفس البيانات إلى اكثر من مضيف ، مثلاً نرغب في نفس سيل الفيديو الى العديد من المتابعين ،ال overhead للإعداد وأدراة عدد كبير من أتصالات TCP سينهك مصادر نظام التشغيل لأن المقبس المختلف يجب ان يستعمل لكل إتصال ، على النقيض من ذلك أرسال مجموعة مرتبة من UDP datagrams التي تستعمل مصادر ضئيلة جداً ،بسبب اننا نستطيع أعادة استخدام نفس المقبس للإرسال الرزم الى العديد من المضيفين ايضاً لايمتلك آليات تحقق من وصول البيانات كما ذكرنا سابقاً .

دائماً يستخدم TCP لإتصال بين جهاز الى جهاز أخر تسمى بعلاقة one-to-one ، بينما يمنح UDP التناقل بين جهاز إلى أجهزة اخرى تسمى بعلاقة one-to-many ايضاً يمنح التناقل بين أجهزة إلى أجهزة اخرى تسمى بعلاقة many-to-many ، فمثلاً على النهاية الاولة one end للسلسة الأجهزة يمكننا عنونة الUDP datagram الى عنوان البث "broadcast address," والبث broadcasting اي الرسائة لجميع المضيفين المستمعين على الشبكة المحلية LAN ، وعلى النهاية الاخرى من سلسة الأجهزة يمكنك أستهدف(إلتقاط تأكد! ) الرسالة لمجموعة المعينة المسبقة للمضيفين بإستخدام "multicast" الوسيلة الحديثة لتضميانات IP وهذة الميزات مقدمة في الفصل 20 و 21 .

خدمة DNS مثال مستند على بروتوكول UDP المسؤلة لترجمة أسماء المضيفين الى عناوين IP أو العكس بغض النظر عن نظام التشغيل المستخدم ، الأستخدام شبكة loose-knit network الخوادم DNS servers ، وأذا لم يحصل العميل على الرد response من DNS server سيعيد أرسال طلبة request ، والoverhead لرزمة البيانات المفقودة التي تخلاء عنها يفوقه قيمتاً من الoverhead لإعداد أتصال TCP جديد لكل طلب ، وهناك امثلة عديدة لخدمات UDP مثل Sun's Network File System (NFS) و Trivial File Transfer Protocol (TFTP)، الاخير مستخدمة من قبل محطات العمل diskless workstations أثناء الأقلاع لكي يشحنهم نظام التشغيل على الشبكة ،يختار UDP أصلاً لهذة الاغراض لان تضمناتهم هي صغيرة نسبياً لذا يلائم UDP بسهولة أكثر الى محدودية فضاء ROM المتؤفرة للمحطات العمل في ذلك الوقت البروتوكول مصمم .

للإطلاع اكثر بروتوكول TCP/IP في [[Stevens 1994], [Wright and Stevens 1995], [Stevens 1996]], وايضاً في RFC 1180, A TCP/IP Tutorial .

عنونة المقبس

لكي تخاطب العملية مع اخرى فلكلاً منهما يجب أن يعرف عنوان الآخر ، فكل مجال في الشبكات لدية مفهوم مختلف للعنوان فمثلاً مجال AF_UNIX يستعمل فقط بين عمليتين على نفس الجهاز التي عنوانها هي المسارات على filesystem في المضيف فمثلاً المسار /usr/tmp/log ، بينما مجال الإنترنت AF_INET فلدى كل عنوان مقبس socket address لدية ثلاثة أجزاء وهم:

1. عنوان IP

2. البورت

3. البروتوكول

عناوين بروتوكول الإنترنت IP addresses

لكل جهاز كمبيوتر مرتبط بالإنترنت أو الشبكة المحلية عنوان IP فريد يميزه عن غيره من الأجهزة الأخرى في الشبكة يستخدم كمعرف او لتعريف وصلة الشبكة على الجهاز المضيف لكي نتعرف على موقعة على الشبكة ويسمح لة بإلاتصال بغيرة من الاجهزة فمثلا في شبكة الأنترنت لايوجد رقمين متشابهين وفي شبكة خاصة لو تم تعين رقمين متشابهين لن يستطيعوا الإتصال في ما بينهم ، فمجموعة الشبكات الفرعية وجداول التوجيهات subnetworks and routing tables التي يستطيع منها أي جهاز على الإنترنت من أرسال الرزم الى جهاز اخر مستند على عنوان IP الخاص به.

يعرف عنوان IP بأنة معرف عددياً بطول 32 بت في النسخة IPv4 الحالية ، ويقسم هذا العنوان ذو القيمة العددية إلى أربعة أقسام تتكون من 32-bit أو 4-byte لعنوان IP توضع في أربع أرقام عشرية وكل قسم مفصول بنقطة لأنشاء مايعرف بشكل "dotted quad address" فمثلاً العنوان 143.48.7.1 المقروء في الميزان العشري كما يمكن تمثيل ذلك العنوان في الميزان السادس عشر 0x8f3071 ، وبما أن كل قسم مكونه من 8 بت فيمكن أن يكون أي قسم من الرقم 1 ألى 255 (2^8 ) لذلك تمنح مخطط العنوانة في نسخة IPv4 حوالي (2^32) 4,294,967,296 عنوان محتمل ، وبما إن من الصعب تذكر هذه الأعداد فأن عناوين بروتوكول الإنترنت تترجم إلى اسماء سهلة تدعى اسماء المجالات Domain names

العديد من برامج الشبكات في البيرل تتطلب عناوين IP في شكل رزمة ثنائية مضغوطة ، ويمكن تحويل عناوين IP الى صيغة ثنائية ثم أعادتها مرة اخرى بأستخدام pack() و unpack() بتضمين الخيار "C4" (لأربعة حروف موجبة unsigned ) ، فعلى سبيل المثال لتحويل 18.157.0.125 الى شكل رزمة مضغوطة ومن ثم عكس العملية :

($a,$b,$c,$d)      = split /\./, '18.157.0.125';
$packed_ip_address = pack 'C4',$a,$b,$c,$d;
($a,$b,$c,$d)      = unpack 'C4',$packed_ip_address;
$dotted_ip_address = join '.', $a,$b,$c,$d;

لان تحتاج الي هذة الدوال عادتاً وهناك لدى البيرل بعض الدوال العالية المستوى لمعالجة هذة التحويل .

أغلب المضيفين لديهم عناونين ، عنوان "loopback address" (وهو العنوان 127.0.0.1 و رمزياً "localhost" ) وعنوانة الإنترنت العام IP ، يرتبط عنوان loopback مع الجهاز لإعادة الإرسال في لوب متكرر وذلك إلى نفسة ،فهذا العنوان ينمحة العميل على المضيف لصنع إتصال إلى الخادم المشغل في نفس المضيف وهو مفيد ويستخدم لتجربة وتطوير البرامج في الجهاز المحلي بدون إي وصول الى الشبكة .

بينما يرتبط عنوان الأنترنت العام مع بطاقة وصلة شبكة network interface card(NIC) المضيف مثلاً كبطاقة Ethernet ، ويخصص عنوان المضيف أما عن طريق مدير الشبكة أو في الإنظمة عن طريق عنونة المضيف ديناميكياَ بواسطة Boot Protocol (BOOTP) أو Dynamic Host Configuration Protocol (DHCP) server ، واذا لدى المضيف العديد من وصلات الشبكة مركبة فلكل وصلة لديها عنوان IP مميز عن الآخر ،وايضاً من الممكن أضافة إعدادات للوصلة الواحدة لكي تستخدم العديد من العناوين في الفصل 21 نناقش IO::Interface التي من ضمن وحـدات البيرل الاضافية third-party التي تمنح فحص وتعديل عناوين IP المخصصة الى بطاقات وصلتها .

Reserved IP Addresses, Subnets, and Netmasks

لكي تغادر رزمة المعلومات من مكان الى اخرى عبر الأنترنت فيجب ان تكون hop عبر مجموعة متتالية من شبكات فيزيائية ، مثلاً تغادر الحزم من جهازك عبر شبكتك الداخلية LAN الى الموديوم أو الروتر ، ثم تعبر إلى مزود خدمة الأنترنت Internet service provider's (ISP) في منطقتك ، ثم عبر خطوط الشبكة الرئيسية backbone مزود خدمة الإنترنت ISP أخر في الشبكة وأخيراً الى الجهاز المستقبل .

تستخدم روترات الشبكة لتتبع كيفية الإتصال البيني(interconnect) بالشبكة وهو المسئول لمعرفة أفضل طريق route كفاءتاً للحصول على الرزمة من النقطة A إلى النقطة B ،على اي حال اذا عناوينIP كانت موطنة لهذا الغرض بالذات ، فأن هذة المهمة لن تكون ممكنة لأن لكل روتر يجب أن تبقي خريطة مشاهدة المواقع locations لجميع عناوين IP ، بدلاً من ذلك عناوين IP توطن في قطع مجاورة لإستخدام في المنظمات وشبكات الإقليمية (مزودات الخدمة )

لتوضيح اكثر يعمل أديسون مؤلف الكتاب في شركة Cold Spring Harbor Laboratory (CSHL) اكتساب فيها الخبره الواسعة في مجال العمل ، تشمل هذة الشركة كتلة من عناوينIP يتروح مدئها من 143.48.0.0 الى نهاية 143.48.255.255 (ويسمى هذا بعناوين الصنف B )، وعندما يشاهد الروتر الرئيسي backbone router رزمة معنونة إلى عنوان IP في هذا المدى فسيحتاج فقط لمعرفة كيفية حصول الرزمة إلى شبكة CSHL's ،ومن ثم هي مسئولية روترات شركة CSHL's لحصول أو لإعطى الرزمة إلى هدفها ، وعملياً مدى عناوين أجهزة شركة CSHL والشركات الكبيرة الاخرى تقسم إلى العديد من الشبكات الفرعية وتستعمل الروترات لربط أجزاءها وذلك لتحسين أداة الشبكة وتسهيل إدارة الشبكة وحل مشاكلها .

الحاسوب الذي يرسل رزمة IP packet يجب علية أما بمعرفة الجهاز المستقبل بأن يصل إلية مباشرتاً (مثلاً عن طريق Ethernet) أو سواءاً يجب أن تمر الرزمة إلى الروتر الذي يربط بين الشبكة المحلية إلى شبكة محددة عن بعد ، وسوءاً كانت الرزمة هي لجزء من شبكة محلية أو لجزء من شبكة اخرى بعيدة تم الاصطلاح على تقسم عناوين IP الى جزءين جزء المضيف وجزء الشبكة ، فمثلاً في شبكة CSHL's يقسم العنوان الى نوعين :أول جزء 143.48. هو جزء الشبكة وبقية الجزء لجزء المضيف ، ولذا فأن أول عنوان في شبكة CSHL's هو 143.48.0.0 وأخر عنوان هو 143.48.255.255

حيث تقسم network/host لأغراض التوجيه routing ، وتستخدم الشبكات ال netmask التي هي الbitmask مع أول في مواقع جزء الشبكة من عنوان IP ، ويكتب عنوان netmask كما هو لعنوان IP في شكل dotted-quad ، و في مثالنا CSHL لها عنوان netmask الأفتراضي 255.255.0.0 الذي هو في الميزان الثنائي 11111111,11111111,00000000,00000000.

قسمت شبكات IP إلى ثلاثة أصناف وتسمى على الترتيب الصنف A و B و C ، بضمن netmasks لكل صنف كما في الجدول ، شبكات الصنف A لديها netmask افتراضي 255.0.0.0 ومايقارب 16 مليون مضيف تقريباً ، وشبكات الصنف B لديهاnetmask الافتراضي 255.255.0.0 مايقارب 65,534 مضيف ، وشبكات الصنف C لديها netmask الافتراضي 255.255.255.0 مايقارب 254 مضيف (حيث أول مضيف وأخر مضيف في المدى لايوفر للإستخدام كمضيف عادي ).

الإنترنت أصبح أكثر إزدحاماً على اي حال فالشبكات تقسم بأكثر الطرق مرونة ،فهي الان موحدة لرؤية netmasks التي لاتنتهي بحدود البايت ،فعلى سبيل المثال عنوان netmask ال 255.255.255.128 (في الميزان الثنائي 11111111,11111111,11111111,10000000 ) يقسم البايت الاخير في مناصفة ، ينشأ مجموعة شبكات من 126-host ، فالرزم Internet routes packets الحديثة مستندة على هذا المخطط الأكثر مرونة يسمى بال Classless Inter-Domain Routing (CIDR) ، تستعمل CIDR مصلح حول تخطيط الشبكات التي فيها عنوان الشبكة يلية slash و عدد صحيح يحتوي العدد 1s في القناع ، فمثلاً في شبكة CSHL's في مصلح عنوان CIDR يكتب بصورة 143.48.0.0/16 ، ولمعرف تفصيل CIDR في RFCs 1517 through 1520 وفي قائمة FAQs في Appendix D.

لفهم عناوين الشبكة و broadcast يمكن أن تكون مشوشة عندما تعمل مع netmasks التي لا تنتهي في حدود البايت ،وحدة Net::Netmask المتؤفرة على CPAN تزود الوسائل لحساب هذة القيم في طريقة بداهية ، وستجد وحـدة أصغر في الملحق A ( Net::NetmaskLite ) كتبت لغرض هذا الكتاب والتعلم في معرفة العلاقة بين عنوان الشبكة وعنوان broadcast و netmask .

العنوان الاول والاخير في الشبكة الفرعية لها أهمية خاصة ولايمكن ان تسخدم كعناوين للمضيف ، العنوان الاول أحياناً معروف بالعنوان جميعه أصفار ، وهو محجوز للإستخدام في جداول التوجيه routing tables للدلالة على الشبكة ككل ، العنوان الأخير في المدى معروف بالعنوان جميعه 1 وهو محجوز لإستعمال كعنوان بث broadcast address و الرزم IP packets التي ترسل الى هذا العنوان ستسلم الى جميع المضفين على الشبكة الفرعية ، فمثلاً الشبكة 192.18.4.x ( عنوان الصنف C أو 192.18.4.0/24 في صيغة CIDR ) عنوان الشبكة هو 192.18.4.0 وعنوان البث هو 192.18.4.255 ونناقش لاحقاً ال broadcasting في الفصل 20 بالتفصيل .

بالإضافة لدى عنوان ip العديد من ranges يدِّخر للأغراض الخاصة (كما في الجدول ) ، فالشبكة الصنف A هو 10.x.x.x ، وشبكات 16 للصنف B هو 172.16.x.x through 172.31.x.x ، وعناوين 255 الصنف C هو 192.168.0.x through 192.168.255.x التي تحجز للإستخدمات في الشبكات الداخلية ، وقد تستخدم الشركات أي من هذة الشبكات لكن يجب ان لاتتصل مباشرتاً الى الإنترنت ، تسخدم شبكات 192.168.x.x كثيراً في الإختبارات والتجربة أو يوضع أنظمة firewall خلفها التي تترجم جميع العناوين الشبكة الداخلية الى عنوان IP عام فريد ، وتحجز عناوين الشبكة مابين 224.x.x.x through 239.x.x.x للتطبيقات multicasting (في الفصل 21) وكل شيء محجوز فوق 240.x.x.x للتوسيعات المستقبلية .

Network Ports

عندما تصل الرسالة الى عنوان IP المستقبل ،لابد ان يشترك المضيف في رقم البورت المفتوح مع الخوادم لمعرفة البرنامج الصحيح لتسليمه والتعامل معة ، وفي حالة كان رقم المنفذ مختلف فقد يحدث لبس واختلاط الرسائل بين تطبيقات الانترنت لذلك تم الإتفاق على تصميم جزء رقم المنفذ في عنوان المقبس socket address مسبقاً بين تطبيقات الإنترنت ، وشمل بأن يكون عنونة المنفذ من 16-bit أو 2 مرفوعة الى الأس 16 أي يتراوح مابين 1 إلى 65535 ، وعلى ان يكون لكل مقبس نشط معرف فريد في النظام الشبكي للجهاز المضيف ، عندما ينشاء البرنامج مقبس فأن نظام التشغيل يسأل عن رقم المنفذ المرتبط مع هذا المقبس فأذا لم يكن المنفذ مستخدم يمنح نظام التشغيل هذا الطلب ويرفض البرامج الاخرى من الوصول الى المنفذ حتي يصبح المنفذ لم يعد في قيد الإستخدام ، في حالتة لم يحدد طلب منفذ معين في البرنامج يعطى الية أحد من الpool للإرقام البورت الغير مستخدمة في نظام التشغيل pool of unused port numbers .

هنالك مجموعتين لأرقام المنأفذ وهي الأرقام التي تستخدم مع مقابس TCP واخر تستخدم مع البرامج المستندة على بروتوكول UDP ، فمن الممكن أستخدام نفس أرقام البورت للبرامجين لكن ان يكون البرنامج الاول TCP والاخر UDP .

ان أرقام البورت مابين 0 الى 1023 محجوزة للإستخدام للخدمات المعروفة على الاإنترنت التي تعرف "well-known services المخصصة من قبل ICANN Internet Corporation for Assigned Names and Numbers فعلى سبيل المثال TCP port 80 محجوز لإستخدام HTTP التي تستعمل في Web servers و TCP port 25 محجوز لإستخدام SMTP التي تستعمل في e-mail transport agents ، كذلك UDP port 53 محجوز لإستخدام domain name service (DNS) ، على نظام اليونكس فقط مستخدم الروت من يمنح إنشاء المقبس بإستخدام بروت محجوز ، وهذا لمنع الغير مخولين من المستخدمين بتشيغل الكود والتفاعل مع العمليات وخدمات الشبكة المضيف .

في المحلق C قائمة المنافذ المحجوزة والخدمات المرتبطة المقابلة ، اغلب الخدمات مستندة على بروتوكول TCP أو على بروتوكول UDP لكن يمكن لبعض برامج الإتصالات مستندة على كلاً منهما ولبعض الإتفاقيات المستقبلية في الأهتمام عادتاً ICANN تحجز كلاً من منأفذ UDP and TCP لكل خدمة وعلى أي حال فهناك العديد من الاختلافات حول هذة القاعدة فمثلاً يستخدم TCP port 514 على نظام اليونكس لخدمات remote shell (login) بينما يستخدم UDP port 514 لمراقبة الدخول النظام system logging daemon.

في بعض نسخ اليونكس المنأفذ مابين 49152 الى 65535 محجوزة من قبل نظام التشغيل لإستعمال كالمنافذ عابرة "ephemeral ports" لتكون مخصص بشكل آلياً إلى أتصالات TCP/IP الخارجة عندما رقم المنفذ مالم يكن مطلوب بشكل واضح ، وباقي المنأفذ مابين 1024 الى 49151 غير محجوزة وتستعمل لإستعمالات تطبيق المستخدم والافضل فحص المنفذ عن طريق أدوات تحليل الشبكة Network Analysis Tools قبل كتابة اي برنامج .

تركيب sockaddr_in

أي عنوان مقبس socket address يجمع بين عنوان المضيف والمنفذ مضغوط في رزمة واحدة سويتاً في تركيب ثنائي يسمى sockaddr_in المقابل لتركيب السيء بنفس الاسم التي تستخدم داخلياً لإستدعاءات روتينات النظام الخاصة بالشبكة (بالمقابل تستخدم مقابس مجال UNIX تركيب رزمة مضغوطة تسمى sockaddr_un ) ، تؤفر البيرل هذة الدوال عن طريق وحـدة Socket القياسية التي تزود لإنشاء ومعالجة تركيبات sockaddr_in بسهولة :

$packed_address = inet_aton($dotted_quad) 

$dotted_quad = inet_ntoa($packed_address)  

$socket_addr = sockaddr_in($port,$address) 

($port,$address) = sockaddr_in($socket_addr)

$socket_addr = pack_sockaddr_in($port,$address) 

($port,$address) = unpack_sockaddr_in($socket_addr)

هناك بعض المراجع لا توضح عنوان المقبس ويشير بالاسم "name." المخصص إلية ، لاتدع هذا يربكك فعنوان المقبس وأسمة هو نفس الشيء .

A Simple Network Client

لوضع هذة المعلومات في سياق العميل للخدمة daytime المشغلة في معظم مضيفين اليونكس التي توضع الى الإستماع لإتصالات القادمة على المنفذ TCP port 13 ، وعندما يتصل العميل بالخادم ينتج في الخرج الوقت والتأريخ الحالي

#!/usr/bin/perl
# file: daytime_cli.pl
# A Daytime Client

use strict;
use Socket;

use constant DEFAULT_ADDR => '127.0.0.1';
use constant PORT         => 13;
use constant IPPROTO_TCP  => 6;

my $address = shift || DEFAULT_ADDR;
my $packed_addr = inet_aton($address);
my $destination = sockaddr_in(PORT,$packed_addr);

socket(SOCK,PF_INET,SOCK_STREAM,IPPROTO_TCP) or die "Can't make socket: $!";
connect(SOCK,$destination)                   or die "Can't connect: $!";

print <SOCK>;

بوضع عنوان IP لخادم daytime من محث الاوامر مثلاً موقع إرشفة البرامج wuarchive.wustl.edu نضع عنوانة IP هو 64.7.3.43 نحصل على الناتج :

% daytime_cli.pl 64.7.3.43
Sat Jan 6 19:11:22 2001

الشرح :

في بداية السكربت شحن الوحـدة strict لتجنب الاخطاء المشتركة وشحن Socket لاستعمال الثوابت والدوال لبرمجة المقبس ، ثم تعريف الثوابت DEFAULT_ADDR لعنوان IP الأفتراضي 127.0.0.1 عندما لايضع المستخدم العنوان في محث الاوامر ، والثابت PORT لرقم المنفذ لخدمة daytime بينما البروتوكول العددي في الثابت IPPROTO_TCP لبروتوكول TCP المطلوب لبناء المقبس ، من غير الانقة في الكود أستخدام هذة الثوابت في انتائج hard code التي قد تأخر IPPROTO_TCP من عملية النقل في مختلف أنظمة التشغيل ، وسنرى في الفصل القادم معرفة هذة القيم في وقت التشغيل بإستخدام أسماء رمزية .

في الجزء التالي من الكود بناء عنوان المستقبل للمقبس بإستخدام عنوان IP لخادم daytime ورقم منفذ خدمة daytime ، بإستلام العنوان من محث الاوامر أو استخدام عنوان loopback اذا لم يحدد العنوان ، سنحتاج ايضاً الى تجهيز وتحويل العنوان بدالة inet_aton() الى الصيغة الثنائية المضغوطة قبل ان يعبر الى دالة أنشاء المقبس socket ، ثم بناء عنوان المستقبل هو لإنشاء التركيب sockaddr_in التي تضم عنوان IP مع رقم المنفذ بواسطة أستدعاء الدالة sockaddr_in مع رقم البورت وعنوان IP المضغوط .

ثم أستخدام الدالة socket لإنشاء إتصالات endpoint التي تنشاء مقبس stream-style Internet-domain التي تستخدم بروتوكول TCP ، وتأخذ الدالة أربعة وسطاء فاول وسيط SOCK هو المقبض المستخدم للمقبس العميل يمكن إجراء العمليات علية كما تعاملنا مع مقبض الملفات سابقاً ، بأقي الوسطاء هي لعائلة العنوان ونوع المقبس ورقم البروتوكول ، بضمن إستثاء البروتوكول التي لدينا hard-coded وجميع الثوابت المأخوذة من وحـدة socket .

ثم نتصل بالعنوان مع المقبض SOCK لنقطة endpoint الإتصالات المحلية الى الجهاز البعيد لإيصال المقبض إلى المقبس البعيد بإستعمال الدالة connect التي تعيد القيمة true أن نجحت وغير ذلك تعود برسائلة الخطأ مع die .

في السطر الاخير من الكود قراءة البيانات من المضيف البعيد وطباعتها ونستطيع من معالجة SOCK كما في مقابض الملفات كالقراءة والكتابة ، فأما ان يقراء البيانات المرسلة من المضيف البعيد عن طريق <> او الدالة read أو ان يرسل البيانات الى المضيف البعيد بإستخدام print ، في المثال السابق أستعمالنا المعامل <> لقراءة جميع السطور المرسلة من المضيف البعيد ثم اخراجها الى الخرج القياسي .

أسماء الشبكة والخدمات

في المثال الاخير أستخدمنا عنوان IP المضيف البعيد والمنفذ والبروتوكول بالعداد لبناء المقبس ، وعادتاً نرغب في أستخدام الاسم بدلاً من الأعداد لجعل كتابة البرامج أكثر سهولة على المستخدمين لإستخدامة .

قاعدة بيانات خدمة domain name system (DNS) قاعدة واسعة النطاق في الأنترنت التي تترجم أسماء المضفين الى عناوين IP أو العكس ، وتترجم خدمات قاعدة البيانات المحلية من أسماء الخدمة الى الأرقام متنوعة ، وفي هذا الجزء هناك مختلف الدوال التي تمنح ترجمة الأسماء الى الأرقام أو الارقام الى اسماء.

ترجمة أسماء المضفين الى عناوين IP

دوال البيرل gethostbyname() وgethostbyaddr() تترجم اسم المضيف الى عنوان IP مضغوط أو العكس وهم الواجهات الامامية إلى استدعاءات مكتبة النظام التي بنفس الاسم ، وبالإعتماد على تنزيل النظام المنزل فيه يسترجع الإستدعى من ملف ثابت أو قد يكون أكثر من ملف static كال /etc/hosts أو من قواعد البيانات الشبكة المحلية LAN كالNIS أو في كافة الانترنت الواسعة DNS .

($name,$aliases,$type,$len,$packed_addr) = gethostbyname($name); 

$packed_addr = gethostbyname($name);

$name = gethostbyaddr($packed_addr,$family); 

($name,$aliases,$type,$len,$packed_addr) = gethostbyaddr($packed_addr, $family); 

تستطيع الدالة inet_aton() أيضاً من ترجمة أسماء المضيف إلى عناوين IP مضغوطة ، وعموما يمكن إستبدالها بإستدعى الدالة gethostbyname() في سياق scalar :

$packed_address = inet_aton($host);
$packed_address = gethostbyname($host);

أستخدام دالة من الدالتين مسألة ذوق والاختلاف فقط بأن gethostbyname() مبنية على البيرل لكن تستعمل inet_aton() فقط بعد شحن وحـدة socket ، ومن الافضل أستخدام inet_aton() لانها ليست حساسة في سياق القائمة على خلاف gethostbyname().

أمثلة لترجمة أسماء المضفين :

بكتابة برنامج لترجمة قائمة أسماء المضفين الى عناوين IP

#!/usr/bin/perl
# file: ip_trans.pl
# Translating hostnames into IP addresses

use Socket;

while (<>) {
    chomp;
    my $packed_address = gethostbyname($_);
    unless ($packed_address) {
        print "$_ => ?\n";
        next;
    }
    my $dotted_quad    = inet_ntoa($packed_address);
    print "$_ => $dotted_quad\n";
}

المعطى ملف أسماء المضفين المخزن hostnames.txt ويشاهد الخرج مثل :

% ip_trans.pl < hostnames.txt
pesto.cshl.org => 143.48.7.220
w3.org => 18.23.0.20
foo.bar.com => ?
ntp.css.gov => 140.162.3

السكربت التالي لإداء عملية عكسية للمثال السابق بترجمة قائمة عناوين IP الى أسماء المضفين ، وفي المثال استخدام التعبيرات المنتظمة لكل سطر مدخل لفحص عنوان IP الصحيح فأذا كان الأمر كذلك يضغط العنوان بأستخدام inet_aton() ، ثم يمرر العنوان المضغوط الى الدالة gethostbyaddr() المحددة بعنوان عائلة AF_INET كوسيط ، وان نجحت تترجم اسماء المضفيف وتطبع في الخرج.

#!/usr/bin/perl
# file: name_trans.pl
# Translating IP addresses into hostnames

use Socket;
my $ADDR_PAT = /^\d+\.\d+\.\d+\.\d+$/;

while (<>) {
  chomp;
  die "$_: Not a valid address" unless /$ADDR_PAT/o;
  my $name = gethostbyaddr(inet_aton($_),AF_INET);
  $name ||= '?';
  print "$_ => $name\n";
}

$number = getprotobyname($protocol) ($name,$aliases,$number) = getprotobyname($protocol) تأخذ هذة الدالة أسم البروتوكول بالنص كالـ"udp" وتحولة الى القيمة العددية المطابقة ، فهي تسترجع في سياقscalar رقم البروتوكول فقط أما في سياق list تعيد أسم البروتوكول وقائمة الإسماء المتسعارة ورقم البروتوكول ، تعيد الدالة undef أو قائمة فارغة في حالة كان أسم البروتوكول غير معروف $name = getprotobynumber($protocol_number) ($name,$aliases,$number) = getprotobyname($protocol_number) تستخدم هذة الدالة نادراً فهي معاكسة لدالة السابقة التي تقوم بترجمة رقم البروتوكول الى أسم البروتوكول ، فهي تسترجع في سياق scalar أسم البروتوكول كنص ،وفي سياق list تسترجع نفس القائمة المعادة بواسطة الدالة getprotobyname() ،وأن امررنا رقم بروتوكول غير صحيح ترجع هذة الدالة undef أو قائمة فارغة . $port = getservbyname($service,$protocol) ($name,$aliases,$port,$protocol) = getservbyname($service,$protocol) تستخدم هذة الدالة لتحويل أسماء الخدمة فمثلاً لتحويل "echo" الى رقم المنفذ الموافق لهذة الخدمة لكي يعبر لاحقاً الى الدالة sockaddr_in() ، تأخذ هذة الدالة وسيطين أسم الخدمة والبورتوكول المطلوب المقابل لتلك الخدمة ، والسبب في أضافة وسيط البروتوكول بسبب ان بعض الخدمات كالecho تأتي مع كلاً من UDP و TCP وليس هناك ضمان لإستخدام هذة البروتكولات للخدمة بنفس المنفذ ، بالرغم من انها عادتاً بنفس المنفذ . تسترجع الدالة getservbyname() في سياق scalar رقم المنفذ للاخدمة أو اذا كان غير معروف تعيد undef ، وفي سياق list تعيد الدالة قائمة من أربعة عناصر تشمل الاسم الرسمى للخدمة وقائمة aliases التي تلي عادتاً بعد اسم الخدمة في الملف الاعداءات ورقم المنفذ ورقم البرتوكول ، وان كانت الخدمة غير معروفة تعيد الدالة قائمة فارغة . $name = getservbyport($port,$protocol) ($name,$aliases,$port,$protocol) = getservbyport($port,$protocol) عكس الدالة السابقة لترجمة رقم البورت الى أسم الخدمة المقابلة ، أيضاً نفس العاد في السياق لدالة getservbyname().

يمكن من تطوير برنامج Daytime Client السابق مع الدوال لكي يزال hard-coded لمنفذ وأرقام البروتوكول بألاضافة جعل البرنامج أكثر سهولة للاستعمال لكافة المستخدمين وقبول الاسم المدخل لمضيف daytime أما بأسم DNS أو بعنوان IP :

#!/usr/bin/perl
# file daytime_cli2.pl
# Daytime client, using symbolic host and service names

use strict;
use Socket;

use constant DEFAULT_ADDR => '127.0.0.1';

my $packed_addr  = gethostbyname(shift || DEFAULT_ADDR) or die "Can't look up host: $!";
my $protocol     = getprotobyname('tcp');
my $port         = getservbyname('daytime','tcp') or die "Can't look up port: $!";
my $destination  = sockaddr_in($port,$packed_addr);

socket(SOCK,PF_INET,SOCK_STREAM,$protocol)  or die "Can't make socket: $!";
connect(SOCK,$destination)                  or die "Can't connect: $!";

print <SOCK>;

نجد الاختلاف في الكود بإستخدام gethostbyname() لترجمة أسم المضيف المعطى من المحث إلى عنوان IP مضغوط أو استخدام عنوان loopback ،وان المستخدم ادخل عنوان IP بدلاً من أسم المضيف فسوف تضغطه الدالة gethostbyname() في أسلوب الدالة inet_aton() ، وان فشلت في حالة كان أسم المضيف غير صحيح تعيد undef ويخرج من البرنامج مع رسائلة الخطأ .

ونجد أستخدام getprotobyname() و getservbyname() بدلاً من ان تكون الشفرة hard-coding كما هو في السابق ، فالاولى لتحديد رقم بروتوكول TCP والثانية لرقم منفذ خدمة daytime في قاعدة بيانات خدمات النظام ، اذا لم تعمل يخرج من البرنامج مع رسائلة الخطأ .

ثم تماماًَ كمافي السابق يتصل ويقراء البيانات بأستثناء استعملنا رقم البروتوكول المسترجع من قبل getprotobyname() في دالة المقبسsocket() .

يمكن التجربة على http://www.modperl.com/

مصادر أخر لمعلومات الشبكة :

بالإضافة إلى الدالة gethostbyname() وإخوتها هناك وحـدات اضافية في البيرل لوصول المباشر الى الكثير من قواعد البيانات المشتركة الاخر (في الشبكة) لمعلومات الشبكة ، ولان نتعرض اليها بالتفصيل وان كنت مهتم اذا احتجاتهم يمكن الحصول عليها من CPAN .

يعتبر مفهوم المجال Domain من أهم أساسيات التشبيك في عالم الشبكات ، ويمكن شرح مفهوم المجال ببساطة بأنة عبارة عن مجموعة من الخوادم ومحطات العمل تتفق فيما بينها على حفظ وإداراة أسماء وكلمات مرور حسابات المستخدمين والأجهزة في قاعدة بيانات مشتركة يطلق عليها في الونيدوز الدليل النشط Active directory وفي اليونكس NIS والذي بفضلة يستطيع المستخدم الولوج الى حسابه في المجال من أي جهاز كمبيوتر متصل بالشبكة ومنتمى للمجال ويكفي أن يدخل اسمه وكلمة المرور الخاصة بحسابة ليجد نفسه قد دخل الى المجال وحصل على جميع إعداداته وكأنه يعمل من جهازه الخاص الذي اعتاد عليه .

Net::DNS

هذة الوحدة تسيطر على كيفية إعادة حل resolved اسماء المضفين بأستخدام نظام domain name system ،بإلأضافة الى وظائف الدوال gethostbyname() و gethostbyaddr() تسمح وحـدة Net::DNS من جلب وتكرار العملية على جميع المضفيف في المجال ، والحصول على البريد الإكتروني e-mail للمدير الشبكة المسؤل للمجال ، وإيجاد look up الجهاز المسؤولة لقبول البريد الإكتروني للمجال ( الـ "mail exchanger," أو MX ).

Net::NIS

العديد من شبكات اليونكس التقليدية تستخدم Sun's Network Information System (NIS) لتوزيع مختلف الاشياء في النظام الشبكي لمختلف اجهزة الشبكة كتوزيع hostnames, IP addresses, usernames, passwords, automount tables, and cryptographic keys التي تمنح من إعطاء للمستخدم نفس login username, password, and home directories على جميع الأجهزة على الشبكة ،فدوال البيرل الداخلية للوصول الى معلومات الشبكة كالدالة gethostbyname() و getpwnam() تودي وصول شفاف وليست إلى جميع المعلومات بحيث تزود البيرل لوظائف NIS's وحدة Net::NIS لمختلف الوصول لهذة المعلومات حتى الباطنية كالجداول automount .

Net::LDAP

نظام NIS بطي ويزيحه Lightweight Directory Access Protocol (LDAP) الذي ينجز بأكثر مرونة وقابلية ،وهناك بإضافة معلومات اخرى للنوعين NIS, LDAP التي تستعمل أحياناً لخزن عناوين البريد الأكتروني للمستخدمين وأرقام التلفون ومعلومات آخر "white pages" ، وحـدة Net::LDAP تعطيك وصول الى تلك قواعد البيانات .

Win32::NetResource

على نظم شبكات الونيدوز يزود NT domain controller معلومات مباشرة على hosts, printers, shared file systems, ومعلومات الشبكة الاخرى ، توفر وحـدة Win32::NetResources الدوال للقراءة وكتابة هذة المعلومات .

أدوات تحليل الشبكة

نتعرض في هذا القسم لبعض الادوات الاساسية لتحليل الشبكات وتشخيص المشاكل المتعلقة بالشبكة ، أغلب الادوات منزلة على النظام ولمزيد من المعلومات حول أستخدام هذة الادوات الرجاء شاهد الوثائق الشاملة للإعدادات الشبكة وحل المشاكل في حالتة احتوى خلل وإصلاحة network configuration and troubleshooting على [Hunt 1998].

ping

ترسل البينج مجموعة من رسائل ICMP إلى عنوان IP البعيد ويسترجع هذا الامر عدد من الردود responses المردودة من الجهاز البعيد.

يستعمل الامر ping لتأكد من أن الجهاز البعيد مرتبطة بالشبكة والاتصال مازال حيء ، ويستعمل أيضاً لإختبار شروط الشبكة بالنظر الى طول الوقت length of time بين البينج الخارجة outgoing ping والردود القادمة incoming response و عدد البينج الغير مردودة no response ( بسبب اما قد فقدت الرسالة الخارجة أو بفقد الردود القادمة ) ، فمثلاًُ لمعرفة اتصال الجهاز لعنوان IP للياهو 216.32.74.55

% ping 216.32.74.55
PING 216.32.74.55: 56 data bytes
64 bytes from 216.32.74.55: icmp_seq=0 ttl=245 time=41.1 ms
64 bytes from 216.32.74.55: icmp_seq=1 ttl=245 time=16.4 ms
64 bytes from 216.32.74.55: icmp_seq=2 ttl=245 time=16.3 ms
^C

--- 216.32.74.55 ping statistics ---
4 packets transmitted, 3 packets received, 25% packet loss
round-trip min/avg/max = 16.3/24.6/41.1 ms

نرى من الجلسة بانها جيدة الأتصال وأن الزمن المتوسط avg المستغرق للرد 24 ms ولم تفقد أي رزم ، نستطيع ان نعطى للامر بالأسم DNS name بدلاً من العنوان في هذة الحالة يحلل resolve الاسم قبل أن يقوم الامر بعملية pinging للمضيف .

حزمة البينج عادتاً تكتشف من قبل بعض انظمة IDS و firewall على الجهاز البعيد المعد مسبقاً في بلوك ping عدم تمكين عملية البينج الا ان نستطيع من استخدام وسائل اخرى كال telnet وغير ذلك .

nslookup

متوفر الامر في انظمة اليونكس والونيدوز التي تستخدم للإختبار والتحقق من DNS ، ويمكن استخدام الأداة بشكل تفاعلي أو من نأفذ الاوامر عن طريق أستدعاءه مع DNS name للمضيف أو domain كما ترغب لإيجاد look up (المطلوب ) ، يودي الامر بحث عن DNS ثم يرجع عناوين IP ومعلومات DNS الاخرى المقابلة للأسم فمثلاً :

% nslookup www.yahoo.com
Server:  presto.lsjs.org
Address:  64.7.3.44
Non-authoritative answer:
Name:    www.yahoo.akadns.net
Addresses:  204.71.200.67, 204.71.200.68, 204.71.202.160, 204.71.200.74, 204.71.200.75
Aliases:  www.yahoo.com

ونجد من الامر بأن المضيف www.yahoo.com لة أسم رسمي www.yahoo.akadns.net ولة خمسة عناوين IP مخصصة اليه ، وهذا الشيء النمؤذجي لخادم الويب حيث يتزن الطلبات القادمة للاجهزة الفيزيائية المتعددة بخدماتهم في شكل حلقة دائرية round-robin fashion.

traceroute

بينما يخبر الامر ping فقط سواء الرزمة نستطيع الحصول عليها من A الى B ، يعرض برنامج traceroute المسار بالضبط لرزمة الشبكة للوصول إلى هناك ، ويستدعى هذا الامر مع عنوان IP الهدف ، ولكل سطر من الرد يعطى العنوانعلى طول طريق الروتر فمثلاًَ :

% traceroute www.yahoo.com
traceroute to www.yahoo.akadns.net (216.32.74.52), 30 hops max, 40 byte packets
 1  gw.lsjs.org (192.168.3.1)  2.52 ms  8.78 ms  4.85 ms
 2  64.7.3.46 (64.7.3.46)  9.7 ms  9.656 ms  3.415 ms
 3  mgp-gw.nyc.megapath.net (64.7.2.1)  19.118 ms  23.619 ms  16.601 ms
 4  216.35.48.242 (216.35.48.242)  10.532 ms  10.515 ms  11.368 ms
 5  dcr03-g2-0.jrcy01.exodus.net (216.32.222.121)  9.068 ms  9.369 ms  9.08 ms
 6  bbr02-g4-0.jrcy01.exodus.net (209.67.45.126)  9.522 ms  11.091 ms  10.212 ms
 7  bbr01-p5-0.stng01.exodus.net (209.185.9.98)  15.516 ms  15.118 ms  15.227 ms
 8  dcr03-g9-0.stng01.exodus.net (216.33.96.145)  15.497 ms  15.448 ms  15.462 ms
 9  csr22-ve242.stng01.exodus.net (216.33.98.19)  16.044 ms  15.724 ms  16.454 ms
10  216.35.210.126 (216.35.210.126)  15.954 ms  15.537 ms  15.644 ms
11  www3.dcx.yahoo.com (216.32.74.52)  15.644 ms  15.582 ms  15.577 ms

netstat

متوفر الامر في انظمة اليونكس والونيدوز ويستعمل لطباعة مجمل خدمات الشبكة النشطة وجميع الاتصالات المرتبطة ، فمثلاًَ بتشغيل netstat على خوادم الويب والFTP النشطة ينتج التالي

% netstat -t
Active Internet connections (w/o servers)
Proto  Recv-Q  Send-Q  Local Address       Foreign Address          State
tcp         0       0  brie.cshl.org:www   writer.loci.wisc.e:1402  ESTABLISHED
tcp         0       0  brie.cshl.org:www   157-238-71-168.il.:1215  FIN_WAIT2
tcp         0       0  brie.cshl.org:www   157-238-71-168.il.:1214  FIN_WAIT2
tcp         0       0  brie.cshl.org:www   157-238-71-168.il.:1213  TIME_WAIT
tcp         0       0  brie.cshl.org:6010  brie.cshl.org:2225       ESTABLISHED
tcp         0       0  brie.cshl.org:2225  brie.cshl.org:6010       ESTABLISHED
tcp         0    2660  brie.cshl.org:ssh   presto.lsjs.org:64080    ESTABLISHED
tcp         0       0  brie.cshl.org:www   206.169.243.7:1724       TIME_WAIT
tcp         0      20  brie.cshl.org:ftp   usr25-wok.cableine:2173  ESTABLISHED
tcp         0     891  brie.cshl.org:www   usr25-wok.cableine:2117  FIN_WAIT1
tcp         0      80  brie.cshl.org:ftp   soa.sanger.ac.uk:49596   CLOSE
....

يحدد مع الوسيط -t لعرض إتصالات TCP ، والمشاهد في عمود Recv-Q لعدد البايت في buffers المقبس المقروء ، وفي عمود Send-Q لعدد البايت في buffers المقبس المكتوب الية ، وفي Local Address مشاهد اسم ورقم المنفذ لجهاز المحلي وفي Foreign Address للجهاز البعيد remote peers ، وفي عمود State يشاهد حالة الإتصال الحالية .

يمكن أن يستخدم الامر netstat لروية الخدمات التي تتنظر لإتصالات القادمة بالإظافة يمكن من تحديد مقابس UDP ومقابس UNIX-domain ، ايضاً صيغة الامر netstat مختلف بعض الشيء في الونيدوز فمثلاً للحصول على قائمة اتصالات TCP نستعمل الامر netstat -p tcp بدلاً من فوق